Avoiding overload in distributed systems by putting the smaller service in control

AWSがどうEC2のデータプレーンとコントロールプレーンという分散システムを設計したか、という話

コントロールプレーンが適用した構成を、データプレーンが反映させるかとも言える

EC2データプレーンからコントロールプレーンのAPIを叩く様な設計にはしてない。クライアント側が影響しあって同時にリクエストを行いコントロールプレーン側のシステム負荷が急増することが多くなった

https://gyazo.com/369709a3b1664aa207ba8ed663218446

ので、コントロールプレーンはS3バケットに更新された設定を書き込み、データプレーンはそれをポーリング＆ローカルにキャッシュする構成にした

https://gyazo.com/10425dc5b8092dbd25786edf718a282c

とはいえ、これは静的構成でなく、動的に生成される場合は、構成全体を再計算してS3に書き込む...というのがつらくなる

EC2はVPC, IAMロール、EBSなどのコンポーネントを知る必要があるので

また、そもそもポーリングだと、一桁秒以内など早い頻度で反映させたい場合と困る。

なので次に、コントロールプレーン（CP) -> データプレーン（DP）を検討した

ただこれはこれで辛い。CPがDPI一覧をもたないといけないし。

https://gyazo.com/2431a4d4e2ffcd77392304cef7190a7e

ので、一貫したDPのハッシュ値を共有データストアにいれて、CPはそのデータストアにハートビートする。CPは同時にデータストアをスキャンし、一貫したハッシュアルゴリズムで担当のDPIサーバーのサブセットを特定する

ディスカバリの方向をDP -> CPに、制御の適用をCP- >DPにするモデル

https://gyazo.com/99122aab09a97ae940b22b620f32f3c0